home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_1199 / 888 < prev    next >
Internet Message Format  |  1994-08-27  |  15KB
  1. Date: Tue, 19 Jul 1994 12:00:08 -0400 (EDT)
  2. Date: Mon, 18 Jul 94 21:44 EST
  3. Subject: Gem List (fwd)
  4. Subject: Gem List (please post)
  5. Subject:  Re: Gem List (fwd)
  6. Subject:  Re: Gem List (corrected) (fwd)
  7. Date: Tue, 19 Jul 1994 12:00:08 -0400 (EDT)
  8. Mime-Version: 1.0
  9. Precedence: bulk
  10.  
  11. Forwarded message:
  12. >From 0006795560@mcimail.com Tue Jul 19 03:17:39 1994
  13. Date: Mon, 18 Jul 94 21:44 EST
  14. From: "Daniel J. Hollis" <0006795560@mcimail.com>
  15. To: ems <gem-list-approval@world.std.com>
  16. Subject: Gem List (please post)
  17. Message-Id: <72940719024427/0006795560PK4EM@mcimail.com>
  18.  
  19. /yupload
  20. Subject:  Re: Gem List (fwd)
  21.  
  22. Michael:
  23. --------
  24. > >My philosophy is that there should be *NO DISTINCTION ON BUTTON
  25. > >FUNCTIONALITY* whether a window is in the 'background' or 'foreground'.
  26. > >The *SAME BUTTONS* should work on the *SAME WINDOW* whether it's topped
  27. > >or not.
  28. > Get used to it; it is not going to change to match your philosophy.  The
  29. > "top window" is an integral part of GEM.  It has been improved, so that
  30. > you can operate window gadgets in the background, but the philosophy (if
  31. > anything) has become more deeply ingrained.  The application receiving
  32. > keystrokes is the one with the top window, the application that is
  33. > active is the one with the top window, and so on.
  34.  
  35. I didn't make *any* mention about changing the keyboard focus. Why bring
  36. that up at all since it wasn't even mentioned?
  37.  
  38. GEM is not going to change to match my philosophy; so we're writing a
  39. GEM Library to *match* the philosophy. There is no reason why users have to
  40. be stuck in the dark ages in terms of a user interface.
  41.  
  42. Maybe some people enjoy doing things the hard way, maybe you're one of
  43. them? :-) However, some people actually have vision, and try to improve
  44. on things rather than be content living in the past with a piss poor GUI
  45. design.
  46.  
  47. > Here is an idea; why not try MausWind, and be happy.  It will
  48. > automa[t]ically top the window as the mouse passes over it.  It is a very
  49. > nice program, written by Thomas Binder.
  50.  
  51. That is exactly the kind of thing I hate, auto-window-topping. If you had
  52. actually read my message, you would have realized that.
  53.  
  54. > >WinX also lets you 'pull' any window forward one level, or push it back
  55. > >one level (or all the way to the back), without having to 'top' it first.
  56. > >This is handy for rearranging the window stack without having to un-top the
  57. > >application you're currently using.
  58. > Sounds like a nice program; for the PC...  :)
  59.  
  60. It *IS* a nice program. We are implementing concepts from it into X-AES.
  61.  
  62. > >Should be a non-issue, IMHO. The same mouse buttons should have the exact
  63. > >same effect on a window whether it's topped or not. Doing otherwise is
  64. > >totally confusing.
  65. > How is it confusing?  It has been that way from the start.  It isn't as
  66. > if the behaviour suddenly changed and the user wasn't notified.
  67.  
  68. It's confusing in that it's a non-consistent GUI design. There is no reason
  69. why programmers have to be content with atari's stupid mistakes.
  70.  
  71. > > >menu layout
  72. > > This definitely needs discussion.
  73. > What is wrong with the Atari standard menu layout?  It does not have
  74. > any obviously stupid errors or such.
  75.  
  76. Other than the idiotic design in AES 4.x for hierarchical menus.
  77.  
  78. > >Have you actually TRIED this? Are you ASSUMING it will slow things down,
  79. > >or are you speaking from experience having tried this? Try first, then
  80. > >comment later. From experience, the speed difference is so incemantable,
  81. > >that it's not even funny. ANYONE can LIVE with the speed difference:
  82. > >There is none that you can see with the naked eye!
  83. > Slower is slower; if you are going to go to the trouble of doing something,
  84. > why not do it right?
  85.  
  86. We *did* do it right. If you had a copy of the demo program and used it, you
  87. would never be able to tell that we do these so-called "time wasting" things,
  88. unless we told you.
  89.  
  90. > >Face it, this is a *BIG* disadvantage.
  91. > Perhaps, but your library will be just plain *BIG*.  I'd rather recompile,
  92. > than waste memory on features I have no need for.
  93.  
  94. Wrong. Our library is much *smaller* than Gem++, yet has many more features.
  95. The resulting executables that do the *same thing* as the equivalent Gem++
  96. program are generally several times *smaller*, not to mention *faster*.
  97.  
  98. Go figure.
  99.  
  100. > >This is the *key* to background buttons, BTW. And it's *VERY* easy to
  101. > >implement using this method.
  102. > Well of course it is, but that does not mean it should be implemented.
  103. > The 'topped window' is part of GEM, and the user will get confused if
  104. > your program does not use it.  The only excuse for not using it is for
  105. > a toolbar, or as a user-selectable option.
  106.  
  107. Maybe you'll become confused by a straighforward GUI design, but I think
  108. you'll be just about the only one. :-) Changing the mouse button requirements
  109. for selection of a topped dialog and a background dialog are totally against
  110. a sane GUI design. But then again, nobody ever claimed atari is sane :-)
  111.  
  112. --Dan Hollis
  113. ----------
  114. Subject:  Re: Gem List (corrected) (fwd)
  115.  
  116. Michael:
  117. --------
  118. > Please post from your own account, or sign-up the account you are posting
  119. > from.  Would it really be that hard?
  120.  
  121. The account is shared, therefore it would be a bit difficult. :-)
  122.  
  123. > > Sounds like some of us enjoy re-inventing the wheel.
  124. > Some of us do, if the wheel was brain-dead to begin with...  :)
  125.  
  126. Yet you criticize us for improving on the wheel. Where do you draw the line?
  127.  
  128. > >There. That was really difficult wasn't it? Now with the new window
  129. > >installed, it WinLIB PRO handles the dialog, lets you move it, BACKGROUND
  130. > >click buttons with the LEFT mouse button (and not some LAME left-right
  131. > >button simultaneous click, I might add) and close it. WinLIB PRO handles
  132. > >everything for you when you return a FALSE in the window dispatcher code.
  133. > Is this really important?  Three lines of code, five lines of code, who
  134. > really cares?
  135.  
  136. WinLIB PRO was designed after intensive study of over *20* GUI libraries.
  137. It incorporates the best ideas of all of them (we steal from the best, and
  138. forget the rest :-) WinLIB PRO is extremely powerful, yet extremely
  139. easy to use. WinLIB PRO does most of the work for you, with an extremely
  140. straightforward, simple API.
  141.  
  142. WinLIB PRO gives you the most amount of bang for the least amount of
  143. effort (and code wise, WinLIB PRO is very, very efficient. Very very small
  144. executables and very fast execution.)
  145.  
  146. > >From the consistent evasions of my questions, it's obvious you know
  147. > >nothing about extended object types. (And yes, I fully expect you will
  148. > >dodge this
  149. > >statement with yet more doublespeak).
  150. > Exactly what is it you want us to know about them (other than the fact that
  151. > you have supperior knowledge of them).  I'll be the guine[a] pig, then.
  152. > I know nothing of any importance about extended object types; I do not
  153. > use them, and have no particular use for them.  Now what should I know?
  154.  
  155. Other than the fact that they are easily accessable from a resource
  156. editor, and give a programmer much more control over the design of an
  157. interface. It's possible to design complete hierarchical menu bars for
  158. WinLIB PRO from a resource editor using extended object types, and never have
  159. to write special code to support it (unlike AES 4.0 which requires you to
  160. write special support code). Extended object types give you more control
  161. over designing an application visually, rather than code wise. IMHO the
  162. GUI should drive the application, not the application drive the GUI. Isn't it
  163. the job of a GEM library to make programming easier, not more difficult?
  164.  
  165. >>> 1) They're afraid of GNU C/C++, since it's not a commercial product.
  166. >>Wrong. I have no problems with using PD compilers. The reason I stay away
  167. >>from Gnu C/C++ is that I don't have the resources to waste (i.e. tons of
  168. >>RAM, and tons of diskspace). And the fact that Gnu C++ spits out binaries
  169. >>roughly 5 to 20 times bigger than the *same code* in Pure C.
  170. > This figure is... <censored>.  Try, on average, less than 50%-60% larger.
  171. > There are other public domain compilers, like SozobonX, that produce
  172. > good object code.
  173.  
  174. Sozobon produces good object code? *laughs* I think your standing with most
  175. of the people in this conference has dropped about 20 points f